509_Merzljakova_E.JU._CHeloveko-mashinnoe_vzaimodejstvie_

2. Прописать процедуры для каждой кнопки:

Рис. 7. Переход к слоту для кнопки

кнопка «Открыть», objectName - open_text. Текст должен открываться как на английском, так и на русском языках. Использовать QTextStream;

кнопка «Сохранить», objectName - save_text. Текст должен сохраняться и читаться в файле как на английском, так и на русском языках. Использовать

QTextStream;

кнопка «Очистить», objectName - clear_text.: используя функцию clear() очистить содержимое TextEdit;

кнопка «Выход», objectName - exit_text. Выход из программы с предварительным сохранением содержимого textEdit по запросу.

3. Реализовать автосохранение во временный файл с помощью таймера. Выдавать информацию о произведенном автосохранении. По выходу из программы удалять временные файлы.

Например, можно сделать так:

1.Пишем функцию автосохранения autosave(), в которой будет происходить сохранение текста из TextEdit в том случае, если в Label уже занесен путь

иимя файла (по заданию в Label всегда будет указан путь с именем текущего файла). Имя временного файла формировать так: «имя_temp». Добавляем сообщение QMessageBox::information с информацией об автосохранении (для проверки работы программы).

2.В MainWindow создаем таймер и соединяем сигнал timeout() (запускается по истечении указанного промежутка времени) с нашей функцией.

11

QTimer *timer = new QTimer(this);

connect(timer, SIGNAL(timeout()), this, SLOT(autosave())); timer->start(10000);

4. Создать однократный таймер для показа логотипа вашей компании по истечении определенного промежутка времени. То есть, пользователь открыл программу, поработал заданный вами промежуток времени и затем ему выходит сообщение о том, что, к примеру, «Вы используете нашу программу уже 10 мин. Мы рады, что она вам понравилась» и логотип. Также это может быть сообщение, например, о том, что срок действия пробной версии программы истек.

Однократный таймер создается следующим образом:

QTimer::singleShot(20000, this, SLOT(hello()));

где hello() – ваша процедура, в которой происходит информирование пользователя о вышесказанном; 20000 – временной интервал в миллисекундах, по истечению которого произойдет вызов процедуры hello().

ЛАБОРАТОРНАЯ РАБОТА 4

Цель: создание базы данных, концепция интервью в QtCreator. Требование: каждая подгруппа выполняет общее задание, в соответствии

со своей базой данных.

1.Создать базу данных (тема базы варианту РГЗ), необходимые поля выбрать самостоятельно.

2.Первое окно программы должно информировать пользователя об общем содержании базы данных (например, название и назначение), содержать ваш логотип и предлагать ввести логин и пароль: 1) user 123; 2) admin qwerty.

3.Пароли хранить в отдельном закодированном файле, хранить ключ, способ защиты выбрать самостоятельно.

4.Реализовать функцию «вспомнить пароль». Способ восстановления пароля выбрать самостоятельно.

5.Второе окно должно содержать вывод базы данных в виде «интервью» (QSqlTableModel). Установить режим редактирования базы данных из таблицы только для admin. Для user оставить режим просмотра.

6.В главном меню окна с базой реализовать следующие функции:

1)смена пользователя – возврат к первому окну с закрытием базы;

2)поиск по базе (поля выбрать самостоятельно);

3)смена пароля;

4)создание нового пользователя ‒ функция, доступная только admin.

12

ЛАБОРАТОРНАЯ РАБОТА 5

Цель: создание, чтение, запись XML-файла в среде QtCreator, иерархические списки.

Требование: каждая подгруппа выполняет общее задание, в соответствии со своим XML-файлом.

1. Создать форму для редактора XML-файлов. За основу взять функционал ЛР №2. Также добавить на форму: кнопку «Сохранить как…», TextLabel2, два ProgressBar, treeWidget, кнопку «Обновить», два CheckBox (с надписями «DOM» и «SAX»), horizontalSpacer и скомпоновать:

Рис. 8. Компоновка виджетов на форме

2.По кнопке «сохранить» необходимо сохранять содержимое Edit по текущему пути, указанному в Label1, а по кнопке «сохранить как…» либо при отсутствии текущего пути, открывать диалоговое окно сохранения XML-файла.

3.Производить автосохранение через каждые 3 минуты по текущему пути, указанному в Label1, но во временный файл. По выходу из программы удалять временные файлы. Информацию об автосохранении выводить в Label2 снизу, использовать ProgressBar. Диалоговых окон не выводить! Если путь не указан, автосохранение производить, например, по пути С:\\Temp. Текст автосохранения и прогресс показывать только во время автосохранения, затем скрывать.

13

4.Создать XML-файл 1.xml вручную (содержание по вариантам РГЗ).

5.Кнопка «Обновить» изначально неактивная. Всплывающая подсказка: «Сохраните данные и обновите структуру». После сохранения либо открытия файла кнопка «Обновить» становится активной. При изменении текста в Edit кнопка снова переходит в неактивное состояние.

6.По нажатию на кнопку «Обновить» производить чтение XML сохраненного или открытого файла и вывод его в иерархический список QTreeWidget двумя способами ˗ DOM и SAX в зависимости от указанного в CheckBox. Показывать прогресс при чтении структуры.

ЛАБОРАТОРНАЯ РАБОТА 6

Цель: научиться работать с QNetworkAccessManager.

Требование: каждый студент выполняет работу отдельно.

1.Установить программу HTTP Analyzer.

2.В QtCreator создать приложение с одним окном. Поместить на форму ком-

понент WebView.

3.Провести программно авторизацию на своей странице (любой сайт), использовать QNetworkAccessManager, запросы. Вывести страницу в WebView.

4.Программно скачать со своей страницы фотографию (либо логотип) и имя (либо другие текстовые данные), вывести их на форму слева.

5.Создать строку поиска, выпадающий список и кнопку, поместив их над компонентом WebView. При нажатии на кнопку должен программно посылаться запрос на google, yandex либо другой поисковик, выбранный в выпадающем списке, результат выводить в WebView.

6.В правом нижнем углу формы выводить информацию о погоде на текущий момент с интервалом обновления 1 час (для проверки установить 3 минуты).

ЛАБОРАТОРНАЯ РАБОТА 7

Цель: работа с графикой.

Требование: каждый студент выполняет работу отдельно.

1. Написать простую игру на свой выбор с использованием любых классов для работы с графикой в QtCreator (QPainter, QCanvas, OpenGL, QGraphicsScene).

14

II.Выполнение РГЗ

1.Теоретические сведения

1.1.Проблемно-центрированная разработка интерфейса

Одним из наиболее эффективных подходов к разработке интерфейса с пользователем, предлагаемых в литературе по человеко-машинному взаимодействию, является подход, сфокусированный на задачах, которые нужно решать пользователю – проблемно-центрированный подход. При таком подходе процесс разработки структурируется исходя из специфических задач, которые пользователь должен будет решать с помощью разрабатываемой системы. Эти задачи выбираются на ранней стадии разработки, затем они используются для выявления требований к дизайну, чтобы облегчить выработку решений и их оценку по мере развития проекта. Основные этапы проблемно-центрированного дизайна:

анализ задач и пользователей;

выбор репрезентативных задач;

заимствование;

черновое описание дизайна;

обдумывание дизайна;

создание прототипа;

тестирование дизайна с пользователями;

итерирование;

реализация;

отслеживание эксплуатации;

изменение дизайна.

На этапе анализа задач и пользователей предстоит определить, кто и зачем собирается использовать разрабатываемую систему. Осведомлённость об уровне знаний пользователя позволяет дизайнеру ответить на вопросы о выборе названий пунктов меню, о том, какие материалы включить в обучающий комплект и контекстную помощь, и даже о том, какие возможности должна обеспечивать система. Такие различия среди пользователей как уровень их квалификации, интерес к изучению новых систем, заинтересованность в успехе разработанной системы могут обусловливать многие решения дизайнера, например, какой заложить уровень обратной связи с пользователем, где предпочесть команды, подаваемые с помощью клавиатуры, а где – выбираемые из меню и т. д. Эффективный анализ задач и пользователей требует персонального контакта между командой разработчиков и теми людьми, которые в дальнейшем будут пользоваться системой.

После выработки хорошего понимания пользователей и их задач более традиционный процесс разработки может абстрагироваться от этих фактов и привести к общей спецификации системы и её пользовательского интерфейса.

15

Проблемно-центрированный дизайн предполагает другой подход. Разработчик должен выделить несколько репрезентативных задач, которые будут решаться при использовании системы. Это должны быть задачи, которые пользователи описали разработчикам. Первоначально они могут быть описаны буквально в нескольких словах, но, т. к. речь идёт о реальных задачах, в любой момент в дальнейшем эти описания могут быть расширены до любой степени детальности, чтобы ответить на любые вопросы, касающиеся дизайна интерфейса или анализа предложенных решений. Отобранные задачи должны достаточно полно покрывать всю функциональность системы, и дизайнеру полезно сделать проверочный список всех функций и путём сопоставления его с перечнем задач удостоверится, что желаемое покрытие достигнуто.

На этапе заимствования необходимо найти существующие интерфейсы, с помощью которых пользователи могут выполнить требуемую работу, и затем строить идеи новой системы на их базе насколько это законно и возможно практически. Например, если они используют электронные таблицы, то, может быть, ваш дизайн должен выглядеть как электронная таблица. Существующую парадигму будет легче изучить и удобнее применять для пользователей, т. к. они уже заранее будут знать, как работает большая часть интерфейса. Копирование известных решений также полезно для низкоуровневых деталей интерфейса, таких как размещение кнопок и названия полей меню. Например, пусть спецификация вашей системы требует, чтобы в какой-то момент могла быть выполнена проверка правописания. Тогда вы должны посмотреть на элементы управления в подсистемах проверки правописания в текстовых процессорах, которые в данный момент используют будущие пользователи вашей системы. Будет лучше, если в вашей системе данный интерфейс будет построен таким же образом.

Черновое описание разрабатываемой вами системы должно быть положено на бумагу (обязательно). Это описание не следует оформлять в виде компьютерной программы (пока), даже если вы умеете пользоваться какими-либо системами автоматизации разработки. Такие системы вынуждают вас прикрепляться к конкретным решениям, которые ещё слишком рано делать. На этой стадии команда разработчиков может проводить множество дискуссий по поводу того, какие возможности должна включать в себя система и как они должны представляться пользователям. Дискуссия должна следовать проблемноцентрированному подходу. То есть, если предлагается введение новой возможности, то необходимо определить, решению какой из репрезентативных задач эта новая возможность будет способствовать. Возможности, которые не способствуют решению любой из задач, как правило, должны отбрасываться. Либо же список репрезентативных задач должен быть дополнен реальной задачей, которая требует этой возможности программы.

Никакая авиационная компания не будет разрабатывать и строить реактивный самолёт без предварительного инженерного анализа, который предсказывает основные технические характеристики. Стоимость строительства и риск

16

неудачи слишком велики. Точно так же стоимость построения законченного пользовательского интерфейса и его тестирование с достаточным количеством пользователей для выявления всех проблем неприемлемо высока. Существует несколько структурных подходов, которые можно использовать, чтобы исследовать сильные и слабые стороны интерфейса до его программного воплощения. Данный этап называется этапом обдумывания дизайна. Один из методов состоит в подсчёте количества нажатий клавиш, движений мыши и мыслительных операций (решений), необходимых для выполнения задач, предписанных разрабатываемой системе. Это позволяет оценить трудоёмкость выполнения задач по времени и выявить задачи, требующие слишком много шагов. Такой метод называется GOMS анализом. Другой метод основан на приёме, названном познавательный сквозной контроль (cognitive walkthrough, CWT), и позволяет находить места в дизайне, где пользователь может делать ошибки. Как и GOMS, CWT анализирует взаимодействия пользователей с интерфейсом при решении отдельных задач.

После этапа обдумывания дизайна по его описанию на бумаге, приходит очередь создания макета или прототипа интерфейса, представляющего собой дальнейшую детализацию предстоящей работы, которую можно показать пользователям. Для этого могут использоваться специальные инструменты для создания прототипов, которые позволяют отделить графическую часть интерфейса от логики функционирования системы. На данном этапе не нужно реализовывать систему целиком. Усилия должны быть сосредоточены на частях её интерфейса, нужных для решения репрезентативных задач.

Опыт показывает, что независимо от того, как тщательно был сделан анализ дизайна на предыдущих этапах, существуют проблемы, которые выявляются только при тестировании дизайна с пользователями. Тестирование должно проводиться с людьми, чей уровень образования и специальной подготовки примерно соответствует тому, что будет у реальных пользователей системы. Следует попросить пользователей выполнить одну или несколько репрезентативных задач, решение которых поддерживает система. Здесь оказывается эффективным приём "думать вслух". Вы просите пользователя не только делать необходимые действия для решения поставленной задачи, но и говорить, что он делает и о чём размышляет. Эти комментарии необходимо записывать, так как они дают неоценимые данные для улучшения дизайна системы. Информация, собранная при тестировании системы с пользователями, даёт ответ на многие вопросы: сколько времени потребовало выполнение тех или иных действий и задач в целом, какие допускались ошибки, что вызвало затруднение или удивление у пользователя, даже если это и не привело к ошибке. Записанные комментарии пользователя позволяют понять, почему были допущены ошибки. Без комментариев вы только фиксируете сам факт ошибки, но вынуждены, потом догадываться (додумывать за пользователя), почему это произошло. При анализе действий пользователя и его комментариев может выясниться, что он

17

мыслит не так, как дизайнер системы. Это позволит внести корректировки, позволяющие приблизить интерфейс системы к её предполагаемому пользователю.

Тестирование с пользователями всегда показывает какие-то проблемы с дизайном. Помните, что цель тестирования состоит не в том, чтобы доказать правильность интерфейса, а в том, чтобы улучшить его. Необходимо проанализировать результаты тестирования, соизмеряя стоимость корректировок с серьёзностью возникших проблем, затем доработать интерфейс и протестировать его снова. Серьёзные проблемы могут даже потребовать пересмотра понимания задач и пользователей, т. е. откатить вас на первый этап проблемноцентрированного подхода. Необходимо на каждой итерации помнить, что различные возможности и особенности интерфейса не самостоятельны. Например, переделывание меню для устранения проблемы, возникшей при выполнении одной задачи, может создать проблемы для других задач. Некоторые из таких взаимовлияний могут быть найдены при анализе без пользователей с помощью CWT или аналогичных приёмов. Другие же не выявятся без тестирования с пользователями. Когда следует прекратить итерации? Если были установлены специфические требования практичности, то итерации прекращаются, как только эти требования выполнены. В противном случае прекращение итераций – это управленческое решение, принимаемое на основе баланса стоимости и полезности дальнейших улучшений против необходимости выхода на рынок с законченным продуктом или сроков предоставления его пользователям.

Ключевой руководящий принцип в программной реализации интерфейса состоит в обеспечении возможности его дальнейшего изменения. Постарайтесь предусмотреть некоторую настройку с помощью небольших изменений значений констант и переменных. Например, если вы пишите собственную подпрограмму для реализации специализированного меню, то не закладывайте жёстко в программу такие параметры, как размер, цвет, количество элементов. Постарайтесь также предусмотреть возможность небольших изменений кода, используя ясное разделение на модули. Если доработки в будущем потребуют замены специализированного меню какой-либо более общей функциональной возможностью, доработки кода должны быть тривиальны. Всё это звучит как обычные требования к хорошему стилю программирования и в действительности ими и является. Но это особенно важно для пользовательского интерфейса, который часто занимает более половины кода коммерческого продукта.

Фундаментальный принцип рассматриваемого подхода состоит в том, что команда разработчиков не должна быть изолирована от всей остальной деятельности, связанной с функционированием системы. Если этот принцип уважается, то разработчик должен иметь контакт с пользователями не только в процессе разработки, но и после выпуска системы. Отслеживание эксплуатации ‒ это ключевой момент для всех серьёзных организаций, заинтересованных в своём постоянном присутствии на рынке. Один из методов введения разработчиков в контакт с пользователями – организация поочерёдных дежурств на горячей линии связи с потребителями. Другая важная вещь для больших систем – орга-

18

низация собраний групп пользователей и конференций. Такая работа позволяет лучше понять реакцию пользователей на продукт, который они продают. Эта информация в дальнейшем позволяет улучшить описание задач для новой версии продукта и углубить понимание разработчиком предметной области.

На существующем сегодня рынке компьютеров и программ вряд ли существуют продукты, которые поддерживают свою жизнеспособность без регулярных усовершенствований. Независимо от того, насколько удачно система была спроектирована первоначально, с большой вероятностью она будет терять адекватность с течением лет. Меняются задачи, меняются пользователи, приходит время изменения дизайна. Приёмы работы меняются из-за нового оборудования и программных продуктов. Пользователи приобретают новые навыки и ожидаемые реакции. Разработчики должны стоять вровень с этими изменениями, не только отслеживая состояние той рабочей среды, для которой была предназначена их система, но и развитие всего общества, технологий и методов, потребностей. Следующая версия системы должна не только устранять обнаруженные ошибки и недостатки, но и давать новые возможности пользователям.

Практичность (англоязычный термин – usability) – это одна из важнейших характеристик систем, изучению которой посвящено множество исследований. Управленческая деятельность в серьёзной корпорации может потребовать от вас представить различные показатели, которые количественно измеряют практичность. Требования практичности – это целевые значения для таких характеристик, как скорость выполнения репрезентативных задач и допустимое количество ошибок. Эти показатели могут использоваться, чтобы мотивировать разработчиков и обосновывать решения по распределению ресурсов. Целевые значения могут быть выбраны так, чтобы побить конкурентов или обеспечить функциональные нужды для хорошо определённых задач. Например, в целях успешной конкуренции от интерфейса может потребоваться не только полнота и удобство для пользователя, но и достижение результатов типа сокращение среднего времени выполнения задач пользователя на 20% по сравнению с известными аналогами. Типичным примером специальной разработки в области интерфейса, значительно улучшающим скорость работы, является алгоритм T9 для набора текстов на телефонной клавиатуре.

1.2. CWT-анализ интерфейса

CWT-анализ – это формализованный способ представления мыслей и действий людей, когда они пользуются интерфейсом в первый раз. Аббревиатура CWT означает Cognitive Walkthrough (познавательный сквозной контроль). Всё начинается с того, что у вас есть прототип или детальное описание интерфейса, и вы знаете, кто будет пользователем системы. Вы выбираете одну из задач, решение которых интерфейс должен поддерживать, затем формируете полный письменный список действий, необходимых для выполнения задачи при помощи интерфейса. Далее вы пытаетесь рассказать «правдоподобную историю» о каждом действии, которое должен выполнить пользователь. Для этого необхо-

19

димо давать мотивацию каждого действия пользователя исходя из его предполагаемых знаний, подсказок и реакций интерфейса. Для каждого действия могут обнаруживаться проблемы, мешающие правильному его выполнению. Эти проблемы записываются, но затем вы предполагаете, что они исправлены, и переходите к следующему действию. В результате у вас остаётся список проблем, что является руководством к действию по исправлению (улучшению) интерфейса.

CWT-анализ позволяет обнаружить несколько типов проблем с интерфей-

сом.

1.Поставить под сомнение ваши первоначальные и не вполне обоснованные предположения о том, как мыслит пользователь.

2.Выявлять элементы управления, которые очевидны для разработчика, но могут быть непонятны пользователю.

3.Выявлять затруднения с надписями и подсказками.

4.Обнаруживать неадекватную обратную связь, что может заставить пользователя сомневаться в результате и повторять всё с начала, хотя всё было сделано правильно.

5.Показывать недостатки в текущем описании интерфейса.

CWT-анализ фокусируется в основном на проблемах, которые пользовате-

ли испытывают при первом взаимодействии, не проходя предварительных тренировок. Такая постановка вопроса чрезвычайно важна для некоторых критических систем, таких как банкоматы или терминалы оплаты. Но та же самая ситуация возникает и в сложных программных системах, когда пользователь выполняет какую-либо задачу впервые. Пользователи часто изучают сложные программы постепенно, углубляясь в детали интерфейса по мере возникновения в том необходимости. Поэтому проблемы "первого знакомства" могут возникнуть даже при взаимодействии с давно используемой программой. Если система построена с уважением принципов CWT-анализа, то она позволяет пользователю плавно подниматься с уровня новичка до уровня эксперта.

Многие упускают необходимость сформировать полный и точный список действий для выполнения задачи. То есть они сами точно не знают, как выполнить задачу, и блуждают по интерфейсу, пытаясь отыскать правильную последовательность действий, а потом они оценивают сложность этого блуждания. Иногда, действительно, бывает полезно оценить сложность такого блуждания, но это не метод CWT. В CWT вы должны начинать, имея в руках полный список отдельных элементарных действий, необходимых для выполнения задания. Если в ходе анализа выясняется, что пользователь испытывает затруднения в определении и выполнении одного из действий, то вас интересует не то, как пользователь выйдет из положения, а сам факт того, что проблема возникла и интерфейс нуждается в доработке.

Основные рекомендации по проведению CWT-анализа сводятся к следующему. Вы определили задачу, класс пользователей, интерфейс и корректную последовательность действий. Далее рекомендуется собрать вместе группу раз-

20